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Abstract 


When setting up a Label Switched Path (LSP) in Generalized MPLS 
(GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the 
completion of the signaling process does not necessarily mean that 
the cross-connection along the LSP has been programmed accordingly 
and in a timely manner. Meanwhile, the completion of the signaling 
process may be used by LSP users or applications that control their 
use as an indication that the data path has become usable. The 
existence of the inconsistency between the signaling messages and 
cross-connection programming, and the possible failure of cross- 
connection programming, if not properly treated, will result in data 
loss or even application failure. Characterization of this 
performance can thus help designers to improve the way in which LSPs 
are used and to make applications or tools that depend on and use 
LSPs more robust. This document defines a series of performance 
metrics to evaluate the connectivity of the data path in the 
signaling process. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6777. 
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Les 


Introduction 


Label Switched Paths (LSPs) are established, controlled, and 
allocated for use by management tools or directly by the components 
that use them. In this document, we call such management tools and 
the components that use LSPs "applications". Such applications may 
be Network Management Systems (NMSs); hardware or software components 
that forward data onto virtual links; programs or tools that use 
dedicated links; or any other user of an LSP. 


Ideally, the completion of the signaling process means that the 
signaled LSP is ready to carry traffic. However, in actual 
implementations, vendors may choose to program the cross-connection 
in a pipelined manner, so that the overall LSP provisioning delay can 
be reduced. In such situations, the data path may not be ready for 
use instantly after the signaling process completes. Implementation 
deficiency may also cause inconsistency between the signaling process 
and data path provisioning. For example, if the data plane fails to 
program the cross-connection accordingly but does not manage to 
report this to the control plane, the signaling process may complete 
successfully while the corresponding data path will never become 
functional at all. 


On the other hand, the completion of the signaling process may be 
used in many cases as an indication of data path connectivity. For 
example, when invoking through the User-Network Interface (UNI) 
[RFC4208], a client device or an application may use the reception of 
the correct Resv message as an indication that the data path is fully 
functional and start to transmit traffic. This will result in data 
loss or even application failure. 


Although RSVP(-TE) specifications have suggested that the cross- 
connections are programmed before signaling messages are propagated 
upstream, it is still worthwhile to verify the conformance of an 
implementation and measure the delay, when necessary. 


This document defines a series of performance metrics to evaluate the 
connectivity of the data path during the signaling process. The 
metrics defined in this document complement the control plane metrics 
defined in [RFC5814]. These metrics can be used to verify the 
conformance of implementations against related specifications, as 
elaborated in [RFC6383]. They also can be used to build more robust 
applications. 
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2s 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Overview of Performance Metrics 


In this memo, we define five performance metrics to characterize the 
performance of data path provisioning with GMPLS/MPLS-TE signaling. 
These metrics complement the metrics defined in [RFC5814], in the 
sense that the completion of the signaling process for an LSP and the 
programming of cross-connections along the LSP may not be consistent. 
The performance metrics in [RFC5814] characterize the performance of 
LSP provisioning from the pure signaling point of view, while the 
metric in this document takes into account the validity of the data 
path. 


The five metrics are: 


o Resv Received, Forward Data (RRFD) - the delay between the point 
when the Resv message is received by the ingress node and the 
forward data path becomes ready for use. 


o Resv Sent, Reverse Data (RSRD) - the delay between the point when 
the Resv message is sent by the egress node and the reverse data 
path becomes ready for use. 


o PATH Received, Forward Data (PRFD) - the delay between the point 
when the PATH message is received by the egress node and the 
forward data path becomes ready for use. 


o PATH Sent, Forward Data (PSFD) - the delay between the point when 
the PATH message is sent by the ingress node and the forward data 
path becomes ready for use. 


o PATH Sent, Reverse Data (PSRD) - the delay between the point when 
the PATH message is sent by the ingress node and the reverse data 
path becomes ready for use. 


As in [RFC5814], we continue to use the structures and notions 
introduced and discussed in the IP Performance Metrics (IPPM) 
Framework documents [RFC2330] [RFC2679] [RFC2681]. The reader is 
assumed to be familiar with the notions in those documents. The 
reader is also assumed to be familiar with the definitions in 
[RFC5814]. 
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4. Terms Used in This Document 


o Forward data path - the data path from the ingress node to the 
egress node. Instances of a forward data path include the data 
path of a unidirectional LSP and a data path from the ingress node 
to the egress node in a bidirectional LSP. 


o Reverse data path - the data path from the egress node to the 
ingress node in a bidirectional LSP. 


o Data path delay - the time needed to complete the data path 
configuration, in relation to the signaling process. Five types 
of data path delay are defined in this document, namely RRFD, 
RSRD, PRFD, PSFD, and PSRD. Data path delay as used in this 
document must be distinguished from the transmission delay along 
the data path, i.e., the time needed to transmit traffic from one 
side of the data path to the other. 


o Error-free signal - data-plane-specific indication of connectivity 
of the data path. For example, for interfaces capable of packet 
switching, the reception of the first error-free packet from one 
side of the LSP to the other may be used as the error-free signal. 
For Synchronous Digital Hierarchy/Synchronous Optical Network 
(SDH/SONET) cross-connects, the disappearance of alarm can be used 
as the error-free signal. Throughout this document, we will use 
"error-free signal" as a general term. An implementation must 
choose a proper data path signal that is specific to the data path 
technology being tested. 


o Ingress/egress node - in this memo, an ingress/egress node means a 
measurement endpoint with both control plane and data plane 
features. Typically, the control plane part on an ingress/egress 


node interacts with the control plane of the network under test. 
The data plane part of an ingress/egress node will generate data 
path signals and send the signal to the data plane of the network 
under test, or receive data path signals from the network under 
test. 
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5. A Singleton Definition for RRFD 


This part defines a metric for forward data path delay when an LSP is 
set up. 


As described in [RFC6383], the completion of the RSVP-TE signaling 
process does not necessarily mean that the cross-connections along 
the LSP being set up are in place and ready to carry traffic. This 
metric defines the time difference between the reception of a Resv 
message by the ingress node and the completion of the cross- 
connection programming along the forward data path. 

5.1. Motivation 

RRFD is useful for the following reasons: 

o For the reasons described in [RFC6383], the data path may not be 
ready for use instantly after the completion of the RSVP-TE 
Signaling process. The delay itself is part of the implementation 
performance. 

o The completion of the signaling process may be used by application 
designers as an indication of data path connectivity. The 
existence of this delay and the potential failure of cross- 
connection programming, if not properly treated, will result in 
data loss or application failure. The typical value of this delay 
can thus help designers to improve the application model. 

5.2. Metric Name 
RRFD = Resv Received, Forward Data path 
5.3. Metric Parameters 

o IDO, the ingress Label Switching Router (LSR) ID 

o ID1, the egress LSR ID 

o T, a time when the setup is attempted 


5.4. Metric Units 


The value of RRFD is either a real number of milliseconds or 
undefined. 
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Ira 


Definition 


For a real number dT, 


RRFD from ingress node IDO to egress node ID1 at T is dT 


means that 


o 


o 


ingress node IDO sends a PATH message to egress node ID1, 


the last bit of the corresponding Resv message is received by 
ingress node IDO at T, and 


an error-free signal is received by egress node ID1 by using a 
data-plane-specific test pattern at T+dT. 


Discussion 


The following issues are likely to come up in practice: 


o 


Sun, 


The accuracy of RRFD depends on the clock resolution of both the 
ingress node and egress node. Clock synchronization between the 
ingress node and egress node is required. 


The accuracy of RRFD is also dependent on how the error-free 
signal is received and may differ significantly when the 
underlying data plane technology is different. For instance, for 
an LSP between a pair of Ethernet interfaces, the ingress node may 
use a rate-based method to verify the connectivity of the data 
path and use the reception of the first error-free frame as the 
error-free signal. In this case, the interval between two 
successive frames has a significant impact on accuracy. It is 
RECOMMENDED that the ingress node use small intervals, under the 
condition that the injected traffic does not exceed the capacity 
of the forward data path. The value of such intervals MUST be 
reported. 


The accuracy of RRFD is also dependent on the time needed to 
propagate the error-free signal from the ingress node to the 
egress node. A typical value for propagating the error-free 
signal from the ingress node to the egress node under the same 
measurement setup MAY be reported. The methodology to obtain such 
values is outside the scope of this document. 


The accuracy of this metric is also dependent on the physical- 


layer serialization/deserialization of the test signal for certain 
data path technologies. For instance, for an LSP between a pair 
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dels 


of low-speed Ethernet interfaces, the time needed to serialize/ 
deserialize a large frame may not be negligible. In this case, it 
is RECOMMENDED that the ingress node use small frames. The 
average length of the frame MAY be reported. 


It is possible that under some implementations, a node may program 
the cross-connection before it sends a PATH message further 
downstream, and the data path may be ready for use before a Resv 
message reaches the ingress node. In such cases, RRFD can be a 
negative value. It is RECOMMENDED that a PRFD measurement be 
carried out to further characterize the forward data path delay 
when a negative RRFD value is observed. 


If an error-free signal is received by the egress node before a 
PATH message is sent on the ingress node, an error MUST be 
reported and the measurement SHOULD terminate. 


If the corresponding Resv message is received but no error-free 
signal is received by the egress node within a reasonable period 
of time, i.e., a threshold, RRFD MUST be treated as undefined. 
The value of the threshold MUST be reported. 

If the LSP setup fails, this metric value MUST NOT be counted. 


Methodologies 


Generally, the methodology would proceed as follows: 


o 


Sun, 


Make sure that the network has enough resources to set up the 
requested LSP. 


Start the data path measurement and/or monitoring procedures on 
the ingress node and egress node. If an error-free signal is 
received by the egress node before a PATH message is sent, report 
an error and terminate the measurement. 


At the ingress node, form the PATH message according to the LSP 
requirements and send the message towards the egress node. 


Upon receiving the last bit of the corresponding Resv message, 
take the timestamp (T1) on the ingress node as soon as possible. 


When an error-free signal is observed on the egress node, take the 


timestamp (T2) as soon as possible. An estimate of RRFD (T2 - T1) 
can be computed. 
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o If the corresponding Resv message arrives but no error-free signal 
is received within a reasonable period of time by the ingress 
node, RRFD is deemed to be undefined. 


o If the LSP setup fails, RRFD is not counted. 
6. A Singleton Definition for RSRD 


This part defines a metric for reverse data path delay when an LSP is 
set up. 


As described in [RFC6383], the completion of the RSVP-TE signaling 
process does not necessarily mean that the cross-connections along 
the LSP being set up are in place and ready to carry traffic. This 
metric defines the time difference between the completion of the 
signaling process and the completion of the cross-connection 
programming along the reverse data path. This metric MAY be used 
together with RRFD to characterize the data path delay of a 
bidirectional LSP. 


6.1. Motivation 

RSRD is useful for the following reasons: 

o For the reasons described in [RFC6383], the data path may not be 
ready for use instantly after the completion of the RSVP-TE 
Signaling process. The delay itself is part of the implementation 
performance. 

o The completion of the signaling process may be used by application 
designers as an indication of data path connectivity. The 
existence of this delay and the possible failure of cross- 
connection programming, if not properly treated, will result in 
data loss or application failure. The typical value of this delay 
can thus help designers to improve the application model. 

6.2. Metric Name 

RSRD = Resv Sent, Reverse Data path 
6.3. Metric Parameters 

o IDO, the ingress LSR ID 

o ID1, the egress LSR ID 


o T, a time when the setup is attempted 


Sun, et al. Standards Track [Page 10] 


RFC 6777 LSP Data Path Delay Metrics November 2012 


6.4. Metric Units 


The value of RSRD is either a real number of milliseconds or 
undefined. 


6.5. Definition 
For a real number dT, 
RSRD from ingress node IDO to egress node ID1 at T is dT 
means that 
o ingress node IDO sends a PATH message to egress node ID1, 


o the last bit of the corresponding Resv message is sent by egress 
node ID1 at T, and 


O an error-free signal is received by the ingress node IDO using a 
data-plane-specific test pattern at T+dT. 


6.6. Discussion 
The following issues are likely to come up in practice: 


o The accuracy of RSRD depends on the clock resolution of both the 
ingress node and egress node. Clock synchronization between the 
ingress node and egress node is required. 


o The accuracy of RSRD is also dependent on how the error-free 
signal is received and may differ significantly when the 
underlying data plane technology is different. For instance, for 
an LSP between a pair of Ethernet interfaces, the egress node 
(sometimes the tester) may use a rate-based method to verify the 
connectivity of the data path and use the reception of the first 
error-free frame as the error-free signal. In this case, the 
interval between two successive frames has a significant impact on 
accuracy. It is RECOMMENDED in this case that the egress node use 
small intervals, under the condition that the injected traffic 
does not exceed the capacity of the reverse data path. The value 
of the interval MUST be reported. 


o The accuracy of RSRD is also dependent on the time needed to 
propagate the error-free signal from the egress node to the 
ingress node. A typical value for propagating the error-free 
signal from the egress node to the ingress node under the same 
measurement setup MAY be reported. The methodology to obtain such 
values is outside the scope of this document. 
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The accuracy of this metric is also dependent on the physical- 
layer serialization/deserialization of the test signal for certain 
data path technologies. For instance, for an LSP between a pair 
of low-speed Ethernet interfaces, the time needed to serialize/ 
deserialize a large frame may not be negligible. In this case, it 
is RECOMMENDED that the egress node use small frames. The average 
length of the frame MAY be reported. 


If the corresponding Resv message is sent but no error-free signal 
is received by the ingress node within a reasonable period of 
time, i.e., a threshold, RSRD MUST be treated as undefined. The 
value of the threshold MUST be reported. 


If an error-free signal is received before a PATH message is sent 
on the ingress node, an error MUST be reported and the measurement 
SHOULD terminate. 

If the LSP setup fails, this metric value MUST NOT be counted. 


Methodologies 


Generally, the methodology would proceed as follows: 


o 


Sun, 


Make sure that the network has enough resources to set up the 
requested LSP. 


Start the data path measurement and/or monitoring procedures on 
the ingress node and egress node. If an error-free signal is 
received by the ingress node before a PATH message is sent, report 
an error and terminate the measurement. 


At the ingress node, form the PATH message according to the LSP 
requirements and send the message towards the egress node. 


Upon sending the last bit of the corresponding Resv message, take 
the timestamp (T1) on the egress node as soon as possible. 


When an error-free signal is observed on the ingress node, take 
the timestamp (T2) as soon as possible. An estimate of RSRD 
(T2 - T1) can be computed. 

If the LSP setup fails, RSRD is not counted. 


If no error-free signal is received within a reasonable period of 
time by the ingress node, RSRD is deemed to be undefined. 
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7. A Singleton Definition for PRFD 


This part defines a metric for forward data path delay when an LSP is 
set up. 


In an RSVP-TE implementation, when setting up an LSP, each node may 

choose to program the cross-connection before it sends a PATH message 

further downstream. In this case, the forward data path may become 

ready for use before the signaling process completes, i.e., before 

the Resv message reaches the ingress node. This metric can be used 

to identify such an implementation practice and give useful 

information to application designers. 

7.1. Motivation 

PRFD is useful for the following reasons: 

o PRFD can be used to identify an RSVP-TE implementation practice in 
which cross-connections are programmed before a PATH message is 


sent downstream. 


o The value of PRFD may also help application designers to fine-tune 
their application model. 


7.2. Metric Name 

PRFD = PATH Received, Forward Data path 
7.3. Metric Parameters 

o IDO, the ingress LSR ID 


o ID1, the egress LSR ID 


o T, a time when the setup is attempted 
7.4. Metric Units 


The value of PRFD is either a real number of milliseconds or 
undefined. 
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7.5. 


Definition 


For a real number dT, 


PRFD from ingress node IDO to egress node ID1 at T is dT 


means that 


o 


o 


ingress node IDO sends a PATH message to egress node ID1, 


the last bit of the PATH message is received by egress node ID1 at 
T, and 


an error-free signal is received by the egress node ID1 using a 
data-plane-specific test pattern at T+dT. 


Discussion 


The following issues are likely to come up in practice: 


o 


Sun, 


The accuracy of PRFD depends on the clock resolution of the egress 
node. Clock synchronization between the ingress node and egress 
node is not required. 


The accuracy of PRFD is also dependent on how the error-free 
signal is received and may differ significantly when the 
underlying data plane technology is different. For instance, for 
an LSP between a pair of Ethernet interfaces, the egress node 
(sometimes the tester) may use a rate-based method to verify the 
connectivity of the data path and use the reception of the first 
error-free frame as the error-free signal. In this case, the 
interval between two successive frames has a significant impact on 
accuracy. It is RECOMMENDED in this case that the ingress node 
use small intervals, under the condition that the injected traffic 
does not exceed the capacity of the forward data path. The value 
of the interval MUST be reported. 


The accuracy of PRFD is also dependent on the time needed to 
propagate the error-free signal from the ingress node to the 
egress node. A typical value for propagating the error-free 
signal from the ingress node to the egress node under the same 
measurement setup MAY be reported. The methodology to obtain such 
values is outside the scope of this document. 


The accuracy of this metric is also dependent on the physical- 


layer serialization/deserialization of the test signal for certain 
data path technologies. For instance, for an LSP between a pair 
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of low-speed Ethernet interfaces, the time needed to serialize/ 
deserialize a large frame may not be negligible. In this case, it 
is RECOMMENDED that the ingress node use small frames. The 
average length of the frame MAY be reported. 


If an error-free signal is received before a PATH message is sent, 
an error MUST be reported and the measurement SHOULD terminate. 


If the LSP setup fails, this metric value MUST NOT be counted. 
This metric SHOULD be used together with RRFD. It is RECOMMENDED 


that a PRFD measurement be carried out after a negative RRFD value 
has already been observed. 


Methodologies 


Generally, the methodology would proceed as follows: 


o 


Sun, 


Make sure that the network has enough resources to set up the 
requested LSP. 


Start the data path measurement and/or monitoring procedures on 
the ingress node and egress node. If an error-free signal is 
received by the egress node before a PATH message is sent, report 
an error and terminate the measurement. 


At the ingress node, form the PATH message according to the LSP 
requirements and send the message towards the egress node. 


Upon receiving the last bit of the PATH message, take the 
timestamp (T1) on the egress node as soon as possible. 


When an error-free signal is observed on the egress node, take the 
timestamp (T2) as soon as possible. An estimate of PRFD (T2 - T1) 
can be computed. 


If the LSP setup fails, PRFD is not counted. 


If no error-free signal is received within a reasonable period of 
time by the egress node, PRFD is deemed to be undefined. 
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8. A Singleton Definition for PSFD 


This part defines a metric for forward data path delay when an LSP is 
set up. 


As described in [RFC6383], the completion of the RSVP-TE signaling 
process does not necessarily mean that the cross-connections along 
the LSP being set up are in place and ready to carry traffic. This 
metric defines the time difference between the point when the PATH 
message is sent by the ingress node and the completion of the cross- 
connection programming along the LSP forward data path. 


8.1. Motivation 
PSFD is useful for the following reasons: 


o For the reasons described in [RFC6383], the data path setup delay 
may not be consistent with the control plane LSP setup delay. The 
data path setup delay metric is more precise for LSP setup 
performance measurement. 


o The completion of the signaling process may be used by application 
designers as an indication of data path connectivity. The 
difference between the control plane setup delay and data path 
delay, and the potential failure of cross-connection programming, 
if not properly treated, will result in data loss or application 
failure. This metric can thus help designers to improve the 
application model. 


8.2. Metric Name 

PSFD = PATH Sent, Forward Data path 
8.3. Metric Parameters 

o IDO, the ingress LSR ID 

o ID1, the egress LSR ID 

o T, a time when the setup is attempted 
8.4. Metric Units 


The value of PSFD is either a real number of milliseconds or 
undefined. 
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8:54 


Definition 


For a real number dT, 


PSFD from ingress node IDO to egress node ID1 at T is dT 


means that 


o 


ingress node IDO sends the first bit of a PATH message to egress 
node ID1 at T, and 


an error-free signal is received by the egress node ID1 using a 
data-plane-specific test pattern at T+dT. 


Discussion 


The following issues are likely to come up in practice: 


o 


Sun, 


The accuracy of PSFD depends on the clock resolution of both the 
ingress node and egress node. Clock synchronization between the 
ingress node and egress node is required. 


The accuracy of PSFD is also dependent on how the error-free 
signal is received and may differ significantly when the 
underlying data plane technology is different. For instance, for 
an LSP between a pair of Ethernet interfaces, the ingress node may 
use a rate-based method to verify the connectivity of the data 
path and use the reception of the first error-free frame as the 
error-free signal. In this case, the interval between two 
successive frames has a significant impact on accuracy. It is 
RECOMMENDED that the ingress node use small intervals, under the 
condition that the injected traffic does not exceed the capacity 
of the forward data path. The value of the interval MUST be 
reported. 


The accuracy of PSFD is also dependent on the time needed to 
propagate the error-free signal from the ingress node to the 
egress node. A typical value for propagating the error-free 
signal from the ingress node to the egress node under the same 
measurement setup MAY be reported. The methodology to obtain such 
values is outside the scope of this document. 


The accuracy of this metric is also dependent on the physical- 


layer serialization/deserialization of the test signal for certain 
data path technologies. For instance, for an LSP between a pair 
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of low-speed Ethernet interfaces, the time needed to serialize/ 
deserialize a large frame may not be negligible. In this case, it 
is RECOMMENDED that the ingress node use small frames. The 
average length of the frame MAY be reported. 


If an error-free signal is received before a PATH message is sent, 
an error MUST be reported and the measurement SHOULD terminate. 


If the LSP setup fails, this metric value MUST NOT be counted. 

If the PATH message is sent by the ingress node but no error-free 
signal is received by the egress node within a reasonable period 
of time, i.e., a threshold, PSFD MUST be treated as undefined. 
The value of the threshold MUST be reported. 


Methodologies 


Generally, the methodology would proceed as follows: 


o 


Sun, 


Make sure that the network has enough resources to set up the 
requested LSP. 


Start the data path measurement and/or monitoring procedures on 
the ingress node and egress node. If an error-free signal is 
received by the egress node before a PATH message is sent, report 
an error and terminate the measurement. 


At the ingress node, form the PATH message according to the LSP 
requirements and send the message towards the egress node. A 
timestamp (T1) may be stored locally in the ingress node when the 
PATH message packet is sent towards the egress node. 


When an error-free signal is observed on the egress node, take the 
timestamp (T2) as soon as possible. An estimate of PSFD (T2 - T1) 
can be computed. 


If the LSP setup fails, PSFD is not counted. 


If no error-free signal is received within a reasonable period of 
time by the egress node, PSFD is deemed to be undefined. 
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9. A Singleton Definition for PSRD 


This part defines a metric for reverse data path delay when an LSP is 
set up. 


This metric defines the time difference between the point when the 
ingress node sends the PATH message and the completion of the cross- 
connection programming along the LSP reverse data path. This metric 
MAY be used together with PSFD to characterize the data path delay of 
a bidirectional LSP. 


9.1. Motivation 
PSRD is useful for the following reasons: 


o For the reasons described in [RFC6383], the data path setup delay 
may not be consistent with the control plane LSP setup delay. The 
data path setup delay metric is more precise for LSP setup 
performance measurement. 


o The completion of the signaling process may be used by application 
designers as an indication of data path connectivity. The 
difference between the control plane setup delay and data path 
delay, and the potential failure of cross-connection programming, 
if not properly treated, will result in data loss or application 
failure. This metric can thus help designers to improve the 
application model. 


9.2. Metric Name 

PSRD = PATH Sent, Reverse Data path 
9.3. Metric Parameters 

o IDO, the ingress LSR ID 

o ID1, the egress LSR ID 


o T, a time when the setup is attempted 


9.4. Metric Units 


The value of PSRD is either a real number of milliseconds or 
undefined. 
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Definition 


For a real number dT, 


PSRD from ingress node IDO to egress node ID1 at T is dT 


means that 


o 


ingress node IDO sends the first bit of a PATH message to egress 
node ID1 at T, and 


an error-free signal is received through the reverse data path 
by the ingress node IDO using a data-plane-specific test pattern 


at T+dT. 


Discussion 


The following issues are likely to come up in practice: 


o 


Sun, 


The accuracy of PSRD depends on the clock resolution of the 
ingress node. Clock synchronization between the ingress node and 
egress node is not required. 


The accuracy of PSRD is also dependent on how the error-free 
signal is received and may differ significantly when the 
underlying data plane technology is different. For instance, for 
an LSP between a pair of Ethernet interfaces, the egress node may 
use a rate-based method to verify the connectivity of the data 
path and use the reception of the first error-free frame as the 
error-free signal. In this case, the interval between two 
successive frames has a significant impact on accuracy. It is 
RECOMMENDED that the egress node use small intervals, under the 
condition that the injected traffic does not exceed the capacity 
of the forward data path. The value of the interval MUST be 
reported. 


The accuracy of PSRD is also dependent on the time needed to 
propagate the error-free signal from the egress node to the 
ingress node. A typical value for propagating the error-free 
signal from the egress node to the ingress node under the same 
measurement setup MAY be reported. The methodology to obtain such 
values is outside the scope of this document. 


The accuracy of this metric is also dependent on the physical- 


layer serialization/deserialization of the test signal for certain 
data path technologies. For instance, for an LSP between a pair 
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of low-speed Ethernet interfaces, the time needed to serialize/ 
deserialize a large frame may not be negligible. In this case, it 
is RECOMMENDED that the egress node use small frames. The average 
length of the frame MAY be reported. 


If an error-free signal is received before a PATH message is sent, 
an error MUST be reported and the measurement SHOULD terminate. 


If the LSP setup fails, this metric value MUST NOT be counted. 

If the PATH message is sent by the ingress node but no error-free 
signal is received by the ingress node within a reasonable period 
of time, i.e., a threshold, PSRD MUST be treated as undefined. 
The value of the threshold MUST be reported. 


Methodologies 


Generally, the methodology would proceed as follows: 


o 


Sun, 


Make sure that the network has enough resources to set up the 
requested LSP. 


Start the data path measurement and/or monitoring procedures on 
the ingress node and egress node. If an error-free signal is 
received by the egress node before a PATH message is sent, report 
an error and terminate the measurement. 


At the ingress node, form the PATH message according to the LSP 
requirements and send the message towards the egress node. A 
timestamp (T1) may be stored locally in the ingress node when the 
PATH message packet is sent towards the egress node. 


When an error-free signal is observed on the ingress node, take 
the timestamp (T2) as soon as possible. An estimate of PSRD 
(T2 - T1) can be computed. 

If the LSP setup fails, PSRD is not counted. 


If no error-free signal is received within a reasonable period of 
time by the ingress node, PSRD is deemed to be undefined. 
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10. 


10. 


10 


10. 


10. 


A Definition for Samples of Data Path Delay 


In Sections 5, 6, 7, 8, and 9, we defined the singleton metrics of 
data path delay. Now, we define how to get one particular sample of 
such a delay. Sampling is done to select a particular portion of 
singleton values of the given parameters. As in [RFC2330], we use 
Poisson sampling as an example. 


1. Metric Name 


Type «X» data path delay sample, where X is either RRFD, RSRD, PRFD, 
PSFD, or PSRD. 


.2. Metric Parameters 


o IDO, the ingress LSR ID 

o ID1, the egress LSR ID 

o TO, a time 

o Tf, a time 

o Lambda, a rate in reciprocal milliseconds 

o Th, the LSP holding time 

o Td, the maximum waiting time for successful LSP setup 

o Ts, the maximum waiting time for an error-free signal 

3. Metric Units 

A sequence of pairs; the elements of each pair are: 

o T, a time when setup is attempted 

o dT, either a real number of milliseconds or undefined 

4. Definition 

Given TO, Tf, and Lambda, compute a pseudo-random Poisson process 
beginning at or before TO, with average arrival rate Lambda, and 
ending at or after Tf. Those time values greater than or equal to TO 
and less than or equal to Tf are then selected. At each of the times 


in this process, we obtain the value of a data path delay sample of 
type «X» at this time. The value of the sample is the sequence made 
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10. 


10. 


10. 


10. 


10. 


10. 


up of the resulting «time, type «X» data path delay» pairs. If there 
are no such pairs, the sequence is of length zero and the sample is 
said to be empty. 

5. Discussion 


The following issues are likely to come up in practice: 


o The parameters Lambda, Th, and Td should be carefully chosen, as 
explained in the discussions for LSP setup delay (see [RFC5814]). 


o The parameter Ts should be carefully chosen and MUST be reported 
along with the LSP forward/reverse data path delay sample. 


6. Methodologies 
Generally, the methodology would proceed as follows: 


o Select specific times, using the specified Poisson arrival 
process. 


o Set up the LSP and obtain the value of type «X» data path delay. 


o Release the LSP after Th, and wait for the next Poisson arrival 
process. 


7. Typical Testing Cases 

7.1. With No LSP in the Network 

7.1.1. Motivation 

Data path delay with no LSP in the network is important because this 
reflects the inherent delay of a device implementation. The minimum 
value provides an indication of the delay that will likely be 


experienced when an LSP data path is configured under light traffic 
load. 


7.1.2. Methodologies 


Make sure that there is no LSP in the network, and proceed with the 
methodologies described in Section 10.6. 
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10 


10. 


Il. 


Ti; 


11 


11. 


.7.2. With a Number of LSPs in the Network 


.7.2.1. Motivation 


Data path delay with a number of LSPs in the network is important 
because it reflects the performance of an operational network with 
considerable load. This delay may vary significantly as the number 
of existing LSPs varies. It can be used as a scalability metric of a 
device implementation. 


7.2.2. Methodologies 

o Set up the required number of LSPs. 

o Wait until the network reaches a stable state. 

o Then proceed with the methodologies described in Section 10.6. 
Some Statistics Definitions for Metrics to Report 

Given the samples of the performance metric, we now offer several 

statistics of these samples to report. From these statistics, we can 

draw some useful conclusions regarding a GMPLS network. The value of 

these metrics is either a real number of milliseconds or undefined. 

In the following discussion, we only consider the finite values. 

1. The Minimum of the Metric 

The minimum of the metric is the minimum of all the dT values in the 

sample. In computing this, undefined values SHOULD be treated as 

infinitely large. Note that this means that the minimum could thus 


be undefined if all the dT values are undefined. In addition, the 
metric minimum SHOULD be set to undefined if the sample is empty. 


.2. The Median of the Metric 


The median of the metric is the median of the dT values in the given 
sample. In computing the median, the undefined values MUST NOT be 
included. The median SHOULD be set to undefined if all the dT values 
are undefined, or if the sample is empty. When the number of defined 
values in the given sample is small, the metric median may not be 
typical and SHOULD be used carefully. 


3. The Percentile of the Metric 
The "empirical distribution function" (EDF) of a set of scalar 


measurements is a function F(x), which, for any x, gives the 
fractional proportion of the total measurements that were «- x. 
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Tis 


Ti 


Ili. 


1-2: 


Given a percentage X, the Xth percentile of the metric means the 
smallest value of x for which F(x) >= X. In computing the 
percentile, undefined values MUST NOT be included. 


See [RFC2330] for further details. 
4. Failure Probability 


Given the samples of the performance metric, we now offer two 
statistics of failure events of these samples to report: Failure 
Count and Failure Ratio. The two statistics can be applied to both 
the forward data path and reverse data path. For example, when a 
sample of RRFD has been obtained, the forward data path failure 
Statistics can be obtained, while a sample of RSRD can be used to 
calculate the reverse data path failure statistics. Detailed 
definitions of Failure Count and Failure Ratio are given below. 


4.1. Failure Count 


Failure Count is defined as the number of the undefined value of the 
corresponding performance metric in a sample. The value of Failure 
Count is an integer. 


4.2. Failure Ratio 


Failure Ratio is the percentage of the number of failure events to 
the total number of requests in a sample. Here, a failure event 
means that the signaling completes with no error, while no error-free 
signal is observed. The calculation for Failure Ratio is defined as 
follows: 


Failure Ratio - Number of undefined value/(Number of valid metric 
values + Number of undefined value) * 100$. 


Security Considerations 


In the control plane, since the measurement endpoints must be 
conformant to signaling specifications and behave as normal signaling 
endpoints, it will not incur security issues other than normal LSP 
provisioning. However, the measurement parameters must be carefully 
selected so that the measurements inject trivial amounts of 
additional traffic into the networks they measure. If they inject 
"too much" traffic, they can skew the results of the measurement and 
in extreme cases cause congestion and denial of service. 


In the data plane, the measurement endpoint MUST use a signal that is 
consistent with what is specified in the control plane. For example, 
in a packet switched case, the traffic injected into the data plane 
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MUST NOT exceed the specified rate in the corresponding LSP setup 
request. 
MUST use the specified or negotiated lambda with appropriate power. 


In a wavelength switched case, the measurement endpoint 


The security considerations pertaining to the original RSVP protocol 


[RFC2205] 


13; 


13.1; 


[RFC2119] 


[RFC2205] 


[RFC2679] 


[RFC2681] 


[RFC3209] 


13:525 


[RFC2330] 


[RFC4208] 


[RFC5814] 


[RFC6383] 


Sun, 


and its TE extensions [RFC3209] also remain relevant. 
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